Block-level backups are computer data backups that are performed at the block level, with a block being a group of disk or volume sectors. By dealing directly with data blocks on the source volume, these backup processes bypass the file system. Because each backup may take a long time to complete, block-level backups usually are accomplished using snapshot technology. Snapshots are used to “freeze” the volume or volumes being backed up at a point of time.
Snapshot technology can be implemented using a variety of methods, including Copy-on-Write (COW), Redirect-on-Write (ROW), and Split-Mirror snapshots. The present invention is primarily focused on COW snapshots, which are particularly useful when the backup process is being performed by independent backup software. The COW snapshot technology, which doesn't change the production data flow, is used in this type of process to reduce the impact of the backup on the production machine being backed up. In this case, the snapshot is created at the beginning of the backup process and deleted at the end of the backup.
The traditional process of COW snapshots is shown in connection with FIGS. 1, 2, and 3. The goal of the backup software is to create a copy of the volume as it exists at a particular moment in time. FIG. 1 shows the content of a volume 100. To simplify the explanations involved, this volume 100 presented as having only 8 blocks of possible data. As shown in FIG. 1, each of these eight blocks are assigned a sequence number, and blocks 0, 1, 2, 3, 4, 5, and 6 contain data A, B, C, D, E, F, and G, respectively. Block 7 contains no data.
Backup software tasked with backing up this volume 100, which means that the data within volume 100 (namely A, B, C, D, E, F and G) must be copied to a backup location. This backup process may take a significant amount of time, and during this time a production machine may need to overwrite the data on volume 100. To ensure that the backup software is working on the data as it existed at that time the backup process started, the COW process effectively takes a “snapshot” of the state of the data in volume 100 at the beginning of the process. This snapshot representation of the state of volume 100 is indicated by figure numeral 110. By taking this snapshot 110, the backup process will be able to back up the data on the volume 100 as it existed at the moment the snapshot 110 was created.
The COW process creates this snapshot 110 using a snapshot driver 200 that monitors data being written to the volume 100 during the backup process, as is shown in FIG. 2. When a write request arrives at the volume 100 during the backup, the snapshot driver 200 will intercept the write request and will determine whether the destination blocks for that write already contain data (as is the case with blocks 0-6 of volume 100). If they do, writing the data found in the write request will interfere with the ability to back up the data unless the snapshot driver 200 intervenes. In this case, the COW process implemented by the driver 200 will copy the original data of the intended destination for the write request to a snapshot space 220 before those locations are overwritten. In FIG. 2, blocks 1, 3, 4, 5, and 7 are being written to during the backup. For blocks 1, 3, 4, and 5, the snapshot driver 200 needs to copy the original data B, D, E and F to the snapshot space before writing the new data (B′, D′, E′, and F′) to the corresponding blocks on volume 100. In FIG. 2, the new data for the blocks are shown arriving in a certain order, with block 1 (B′) arriving first (it appears highest in FIG. 2), block 7 (H) next, and then blocks 5 (F′) and 4 (E′), and finally block 3 (D′). Because of this order, the blocks in the snapshot space 220 are ordered B, F, E, and then D. As for block 7 (H), this data will be written to the volume directly without any copying to the snapshot space 220 because the block 7 had not contained any data at the time the snapshot 110 was created.
From the point of view of backup process 300 as shown in FIG. 3, the process will back up the allocated blocks 0, 1, 2, 3, 4, 5 and 6 sequentially from the snapshot 110 taken of volume 100. The snapshot process understands that data A, C, G of blocks 0, 2, 6 can be read directly from the real volume 100, but the data B, D, E, F of blocks 1, 3, 4, 5 will need to be read from the snapshot space 220 because of the COW snapshot process (as shown by redirection lines 310).
For this to work, all the data found in blocks that are updated during the backup process (blocks 1, 3, 4, and 5) are copied to the snapshot space 220. One crucial question that must be addressed in this situation is how much snapshot space 220 must be allocated for the backup process for the COW data to maintain the snapshot 110. Generally, the recommendation is that the snapshot space 220 be approximately 10 percent of the data that is being protected (volume 100). But if the load on the protected system is very high, or the backup process is slowed, the required snapshot space 220 may be quite a bit larger. If the allocated snapshot space 220 is in sufficient, the backup processes will fail.